[アップデート] AWS Organizations で宣言型ポリシー(declarative policies) が利用可能になりました #AWSreInvent
あしざわです。
AWS Organizations の新しいガバナンス機能として、宣言型ポリシー(declarative policies) が登場しました。
このブログは宣言型ポリシーの機能について、概要レベルでまとめたものです。
新機能の概要
宣言型ポリシーを利用することで、特定のAWS サービスのベースライン構成を指定でき、組織全体へ適用できます。
似た機能にSCP やRCP がありますが、それらは承認ポリシーと呼ばれており、宣言型ポリシーとは異なる概念です。
承認ポリシーと宣言型ポリシーの大きな違いは『API レベルで動作するか』または『サービスのコントロールプレーンで適用されるか』という点です。
承認ポリシーはAWS API へのアクセスを制限しますが、宣言型ポリシーはAPI アクションを使用せずにAWS サービス自体に直接適用されます。
宣言型ポリシーのメリットは、今後サービスに新しい機能やAPI が追加された場合でも指定したベースラインが常に適用されるという点のようです。確かに従来のSCP やRCP では新しいAPI が追加された際に抜け道ができてしまっていたため、その対策として嬉しいですね。
承認ポリシー(SCP / RCP) との比較
承認ポリシー(SCP / RCP)と宣言型ポリシーの違いを表した表がこちらです。
SCP | RCP | 宣言型ポリシー | |
---|---|---|---|
目的 | IAMリソースなどのプリンシパルに対する一貫したアクセス制御を定義するため | AWSリソースに対する一貫したアクセス制御を定義するため | AWS サービスのベースライン構成を定義するため |
仕組み | APIレベルでプリンシパルの利用可能な最大アクセス権限を定義する | APIレベルでリソースに対する利用可能な最大のアクセス権限を定義する | APIアクションを使用せず、AWSサービスに必要な構成を指定する |
サービスリンクロールの利用 | × | × | ◯ |
フィードバックの仕組み | SCPエラーで拒否される、カスタマイズ不可 | RCPエラーで拒否される、カスタマイズ不可 | エラーメッセージがカスタマイズ可能 |
サービスリンクロールで動作している点、カスタムエラーメッセージの利用が承認ポリシーとの差異です。
特にカスタムエラーメッセージの利用が気になりました。続報としてのやってみた記事で検証してみたいです。
現時点でサポートしている属性
宣言型ポリシーが現在サポートしている機能は以下です。
- VPC
- VPC のブロックパブリックアクセス
- EC2
- シリアルコンソールアクセス
- AMI のブロックパブリックアクセス
- 許可されたAMI の利用
- IMDS のデフォルト設定
- EBS
- EBS スナップショットのブロックパブリックアクセス
個人的に目新しいなと感じたのは、VPC のブロックパブリックアクセス
と許可されたAMI の利用
です。
「VPC のブロックパブリックアクセス」はつい先日追加された比較的新しい機能です。
また、「許可されたAMI」とはこのアップデートと同タイミングで発表された新機能でした(通りで見覚えがなかった、、
ポリシーの形式
こちらはVPC ブロックパブリックアクセスの例ですが、このようなポリシーとして定義します。
"vpc_block_public_access": {
"internet_gateway": { // (optional)
"mode": { // (required)
"@@assign": "block_ingress" // off | block_ingress | block_bidirectional
},
"exclusions_allowed": { // (required)
"@@assign": "enabled" // enabled | disabled
}
}
}
IAMポリシー に似た形式のSCP やRCP とはまた違っていますね。
参考
Declarative policies - AWS Organizations
まとめ
AWS Organizations に追加された宣言型ポリシー(declarative policies)についてまとめました。
既にやってみた記事も公開されていますので、ぜひこちらの記事も併せて確認ください。
個人的に非常に熱いアップデートだと思いますが、サポート範囲は今のところVPC、EC2、EBS と限定的です。今後のサポート範囲の拡張に期待したいです。
以上です。